那些把程序猿坑惨的缓存设置

作者:杜伟

在码农的世界里,一直以来都有一个信仰:只要应用使用了缓存,性能就会翻倍;用上缓存的应用就像是打通任督二脉的武林高手,内力生生不息。但是今天我想跟各位猿类朋友聊一聊自己在使用缓存时遇到的那些坑(这里主要讲对象缓存应用部分,想了解全面的推荐阅读《架构真经》)。

案例一

前几天突然发现 Redis 监控显示某 Redis 实例内存使用量突破了 14G 大关,当时我就震惊了,这是要翻车的节奏啊。通过 info 指令查看,发现 key 的量并不是太高,所以怀疑有个别业务 value 的 size 比较大,为了保证生产不受影响,从生产上导出 rdb 文件进行分析。通过

rdb -c memory redis_dump.rdb —bytes 1024 -f memory.csv

将大于1024字节的 key 导出。然后进行排序:

sort -t, -k4nr memory.csv |head -n 20

终于找到了罪魁祸首。如下图:

紧急删除该 key 临时解决了问题,经复盘发现,此问题是开发时缓存使用不当,所有信息都不过期,数据只能越增越大。

总结:缓存中放置的应该是热数据,同时缓存策略也存在问题,应该针对每条记录设置不同的 key ,而不是都放在一个 key 下。

案例二

某历史项目最近总是报警(系统负载升高,响应变慢,应用频繁 GC ),只能频繁重启应用。分析 Dump 文件,发现创建的对象非常多,但没有明显的占用大户。于是继续分析占用内存较大的对象,发现都是 Hibernate 的代理对象;接下来去看 Hibernate 的配置,发现开启了二级缓存,同时 Ehcache 中没有控制缓存对象的个数,导致应用启动一段时间后,随着缓存对象的增多,很快会导致 GC 了。于是我们紧急上线,关闭了部分对象的缓存,问题得到了初步缓解。

总结:当使用本地缓存(如 Ehcache )时,一定要严格控制缓存对象的个数及生命周期。由于 JVM 的特性,过多的缓存对象会极大的影响 JVM 性能。

案例三

某个正常运行的应用突然报警线程数高,之后很快就内存溢出。查看日志发现无法连接 Memcached,继而查看 Memcached 配置,发现连接数过高,拒绝连接。而应用连接 Memcached 的超时时间较长,导致请求线程不断堆积,最后应用内存溢出。临时解决方案是先增加 Memcached 的连接数,之后应用修改连接超时时间。

总结:当我们在使用远程缓存(如 Redis、Memcached )时,一定要对超时时间进行控制,一般来讲缓存的总体响应时间不能高于 50ms ,否则缓存会成为应用的负担,而不是帮手。

案例四

某项目关键业务忽然报警业务波动,查看应用日志发现访问 Redis 异常,查看 Redis 发现做了主备切换;这次超时时间设置没问题,但没有针对缓存不可用做降级处理,导致业务流程中断。

总结:使用缓存时,一定要有降级处理;尤其是关键业务环节。

案例五

某项目使用缓存后,开发测试没问题,上生产后,服务却不可用。查看日志发现是该应用的缓存 key 与其他应用缓存的 key 冲突,导致错误。

总结:缓存使用时,一定要有隔离的设计。比如 Redis 可以选择不同的 DB,或者 Ehcache 定义不同的 Cache 名。如果这些都不方便实施,至少也要有 key 的命名规范,否则天知道会发生什么。

案例六

某项目使用 Redis 缓存临时数据,上线后出现错误数据,但由于没有开发管理功能,导致发生问题时,看不到数据,也无法管理,使得应急时间较长。

总结:当使用缓存后,一定提供相应的管理手段。否则发生事故时,只能两眼一抹黑。

案例七

某应用在访问时经常时快时慢,同时 DB 负载也忽高忽低;分析代码发现项目中缓存设置了一个固定的失效时间,当缓存失效时,会造成一段时间内访问 DB 的请求非常集中。

总结:简单方案就是将缓存失效时间分散开,比如我们可以将失效时间设置为一个区间内的随机值,这样每一个缓存的过期时间的重复率就会降低,就很难引发集体失效的事件。

案例八

某计费项目发现计算结果有误差,分析日志时发现:系统修改规则后,较长时间仍在使用旧规则。查看 Ehcache 配置文件发现过期时间很长,导致规则更新后,很长时间不生效,部分订单计算费用出现误差。

总结:使用本地缓存又需要数据一致性时,可以考虑用 Zookeeper 之类的协调服务,实现一个更高效的缓存更新机制。

案例九

这是一个缓存穿透的案例,某模块设计使用了缓存,但发现数据库负载并没有大幅下降。分析代码发现,缓存逻辑如下:数据库存在纪录则放到缓存中,不存在则下次仍然会访问数据库;导致不存在的订单频繁查询时,缓存没有效果。

总结:缓存穿透是一个常见问题,我们需要把 null 也作为一种缓存结果,否则此类情况等于缓存是失效的。

结尾

以上这些案例都是我们亲身经历的血的教训,在研发过程也是很容易忽略的点。诚然使用缓存是提高应用性能的有效手段,但没有深入的分析与设计就很容易造成灾难性的影响。我思故我在,我们猿类最大的优点就是思考能力,希望这些小案例能引起大家更深层次的思考。另外,软件设计思想来源于生活,比如看看 CPU 的设计,有一级缓存、二级缓存,估计有很多小伙伴也在做缓存设计时这样做了。生活中处处有设计,只要用心总能观察到。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 162,710评论 4 376
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 68,839评论 2 308
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 112,295评论 0 255
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,776评论 0 223
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 53,198评论 3 297
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 41,074评论 1 226
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 32,200评论 2 322
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,986评论 0 214
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,733评论 1 250
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,877评论 2 254
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,348评论 1 265
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,675评论 3 265
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,393评论 3 246
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,209评论 0 9
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,996评论 0 201
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 36,212评论 2 287
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 36,003评论 2 280

推荐阅读更多精彩内容